home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1993 July / InfoMagic USENET CD-ROM July 1993.ISO / sources / std_unix / archive / text0019.txt < prev    next >
Encoding:
Text File  |  1993-07-06  |  2.2 KB  |  56 lines

  1. Submitted-by: karish@mindcraft.com (Chuck Karish)
  2.  
  3. In Volume 31, Number 16, amf@amfent.gwinnett.com (Andy Feibus) wrote:
  4. >dave@88open.org (Dave Cline) writes:
  5. >> It seems valid to argue against formal test method standards because:
  6. >> 
  7. >>   c) there is no mechanical way to ensure that both standards
  8. >>      say the same thing.
  9. >Taking this a step further, a test methods standard may not provide
  10. >complete or completely correct test coverage of a standard.  Following
  11. >from that, a test suite based
  12. >on the test methods standard may not properly test the actual technology 
  13. >it intends to verify.
  14.  
  15. At least if you there is a test methods standard, it's
  16. possible to assess how  much coverage there is.  Where
  17. there are test suites that are written as series of ad hoc
  18. exercises for the implementation, there's no clear
  19. specification against which the tests can be examined for
  20. either completeness or correctness.
  21.  
  22. >So, if a test suite is only an implementation of the test methods standard
  23. >and the test methods standard may not completely or correctly test the
  24. >technology, what good is it?
  25.  
  26. It's a much better basis for verifying conformance than
  27. we'd have otherwise.  I can pretty confidently guarantee
  28. that without test methods standards we'd have less
  29. confidence in our test suites and that implementations
  30. would be tested less well than they are now.
  31.  
  32. Rather than compare the POSIX.1 testing situation with that
  33. for ada, I find it instructive to consider the case of the
  34. SVVS.  This test suite was written to test a somewhat
  35. underspecified base document without formalizing the test
  36. assertions.  The result was that the test suite itself
  37. became the de facto standard, with no effective means for
  38. review of its correctness.
  39.  
  40. >Even better -- or, more confusing --
  41. >how do we verify that the test suite is a complete and correct
  42. >implementation of the test methods standard (which may or may not be
  43. >complete or correct)??
  44.  
  45. By reading them carefully, looking at the results when test
  46. suites written to them are run, and correcting the test
  47. suites and the test methods and the base specifications
  48. when we find problems.  Just like any other software
  49. product.
  50.  
  51.     Chuck Karish        karish@mindcraft.com
  52.     Mindcraft, Inc.     (415) 323-9000 x117
  53.  
  54. Volume-Number: Volume 31, Number 20
  55.  
  56.